1. Field of the Invention
This invention relates to apparatus and processes for testing software, and more particularly to apparatus and processes for performing time and date testing in software applications.
2. Background of the Invention
Many of today's enterprises rely on software applications that employ date- and/or time-sensitive processing logic. As an example, utility companies may employ complicated business logic when billing their customers. Such business logic, for example, may take into account that subsidies for electricity are in effect during certain dates and/or times but not during other dates and/or times. Similarly, companies that sell merchandise may charge a different amount of tax based on laws that are in effect at the date/time the merchandise is purchased. In these and other cases, proper time and date handling is critical to application reliability. Unexpected behavior may have serious implications, including high cost, significant system downtime, loss of customers, or the like.
Time and date testing generally involves injecting specific dates and/or times into software applications and checking the results. In the z/OS environment, several programming languages have tools to enable this type of time and date testing. Unfortunately, these tools do not work with Java™ applications as the underlying approach of these tools is unsuitable for the Java™ environment (the term “Java” is a registered trademark which will be referred to hereinafter as simply “Java” or “java”). More specifically, the Java programming model makes it difficult to discriminate between applications that should receive a simulated time and those that must receive a real time. This differs from other programming languages where applications may directly call the operating system for system time, thereby making it easier to intercept and return a simulated time.
The alternative to using testing software is to manually change the system time to a desired simulated time. One drawback of this approach is that it makes it difficult to achieve a desired level granularity, as it is virtually impossible to force precise boundary times down to the millisecond when manually changing the system time. Another drawback is scope, since the simulated time is seen across the entire computing system which may be running other applications that need to see the real time. Other drawbacks include lack of automation (cannot be scripted into easy nightly regression buckets); speed (manually changing the time is time-consuming); and coverage (because of the speed, the number of tests that can be conducted is limited).
In view of the foregoing, what are needed are apparatus and processes to perform time and date testing in environments such as the Java environment. Ideally, such apparatus and processes would be able to discriminate between applications, thereby providing a real system time to certain applications, while providing a simulated system time to other applications.